LLM, 그리고 Agent의 등장으로 개발자라는 직업이 재정의 될 것이며 지금과는 전혀 다른 모습이 될 것이라는 등 다양한 이야기가 오고 가는 요즘이다. 당연한 게 나부터 개발 방식이 50%는 바뀌었다. 혹은 그 이상일지도 모르겠다. 이 정도의 웅성거림은 오히려 조용한 정도다. AI 파도를 직격으로 맞고 있는 IT 업계 종사자라면 누구나 싱숭생숭하지 않을까. 나도 자연스럽게 고민하게 됐는데, 2025년 3월 기준의 생각을 정리하는 것이 좋을 것 같았다. 발전이 참 빠르고 이에 따라 생각도 변해서 굳이 날짜를 명시했다.
협업 대상으로서의 Agent
작년까지만 해도 LLM에 어떻게 질문하면 좋은 답변을 받는지, 어느 영역을 잘하는지 등 LLM을 어떻게 잘 '활용'할 것인가에 집중했다. 이젠 더 이상 활용 대상이 아니다. 그 이상이다. 내 사고를 도와주고, 내가 놓친 부분을 알려주고, 모르는 부분을 알려주는 동료에 가깝다. 근데 심지어 개떡같이 말해도 찰떡같이 알아듣는 동료다. 스스로 질문을 다듬고 프롬프트를 조율하는 것이다. 이를 활용한다고 표현하기엔 과소평가가 아닐까.
제품 개발
제품 개발에는 여러 단계와 프로세스가 존재한다. 수많은 저수준의 작업이 존재한다. 이 모든 과정에서 Agent의 역할이 있지만 우선 코딩이라는 작업에 제한하여 얘기해 보자. 어느 정도 디자인, 요구사항을 보면 어떻게 개발해야겠다는 계획이 머릿속에 잡힌다. 사람의 개발 방식에 따라(보통 숙련도에 따라) UI를 먼저 구현하기도 하고, 데이터베이스 스키마를 먼저 구현하기도 하고, 클라이언트 서버 간의 인터페이스를 먼저 정의하기도 한다. 앞서 말한 모든 단계에서 Agent의 도움을 받을 수 있다.
요구사항을 전달하고 '초벌' 된 스키마를 받을 수도 있고, 어설프지만 레이아웃은 잡혀있는 마크업을 받을 수 있다. MCP의 등장으로 더 완벽에 가까운 초벌을 받을 수 있게 됐다. 이것은 활용이라기보단 협업에 가깝다. 내가 하던 저수준 일의 일부를 가져간 '올라운더 메이커'와의 협업인 것이다. 물론 가끔 실수도 하고 어설픈 구석이 있지만 용인되는 수준이다. 나조차도 완벽하지 않으니까. 오히려 이런 부분에서 인간미가 느껴진달까. 한편으론 안도가 되기도 한다.
그림자 분신한테 '정의된' 일을 시키고 검토하고 남은 10%를 마저 채우는 식으로 작업 방식이 달라지고 있다.
잘 협업하기
잘 협업하려면 우선 Agent를 이해해야 한다. 인간과 협업할 때 상대방에 대한 이해가 중요하다. 직군에 대한 이해도 중요하지만 사람 자체에 대한 이해도 중요하다. 커뮤니케이션이 중요한 이유이다. Agent라고 다를까. 협업의 대상인 것은 동일하기 때문에 Agent에 대한 이해가 필요하다. AI가 무엇인지, LLM은 어떻게 단어의 연속을 생성해 내는지, 나랑 협업하고 있는 이 Agent는 어디에서 데이터를 참조하여 나에게 도움을 주고 있는지 등 협업하기 위해선 협업 대상에 대한 이해가 필요한 것이다.
Coding assistant tool
잘 활용하고 있다. Cursor나 Copilot 등 코드를 작성할 때 사용하는 Editor에 Agent가 들어와 있는 경우, 실제로 타이핑하여 코드를 작성하는 양보다 Agent가 작성하는 코드의 양이 압도적으로 많다. 실제로 측정해 보지 않았지만 90%에 가깝지 않을까. 아무튼 이러한 변화로 키보드에서 Tab의 위상이 높아졌다. 난 Cursor를 주로 사용하고 있고 여러 지시 사항이 담긴 .cursorrules를 적용해 효율을 끌어올리고 있다. 가끔 어떻게 내 의도를 알았는지, 뉴럴링크가 심어진 것은 아닌지 의심이 들 정도로 자동완성을 잘한다. 일반적인 코드일수록 이 현상은 심했다.
인터페이스를 명확히 정의하여 지시하는 경우 implement는 대부분 100% 제대로 구현했고 99% 수준일 경우, 테스트 코드를 작성하게 하여 스스로 수정하게 하면 100% 커버리지를 보여줬다. 함수 signature를 주거나 컴포넌트의 인터페이스를 정의하고 구현은 맡기는 방식이다.
아직까진 이것을 다음 단계의 추상화라고 할 순 없을 것 같다. 아직 흐릿한 JPEG, 100%가 아니기 때문이다. 분명 Assembly 언어가 C언어로 추상화되고 역사적으로 고수준의 프로그래밍 언어가 만들어졌지만, 이것은 약간 다른 방향의 변화라고 생각한다.
앞으로
그래서 어떻게 되는 거냐고. 내 직업이 사라지는 것인가. 불과 몇 년 전까지만 해도 개발자를 데려가기에 바빴는데 분위기로 보아하니 이젠 돈 먹는 하마, 찬밥 신세가 될 지경이다.
Product Engineer
언제부턴가 Product Engineer란 단어가 유행처럼 번지기 시작했다. 대충 어떤 느낌인진 알 것 같다. 대부분의 사람이 개발의 경계가 사라지고 제품 개발자(Product Engineer), 풀스택 개발자(Fullstack Developer)로 통합될 것이라고 하는데, 난 조금 생각이 다르다.
제품 전반을 담당할 때 장점은 두 가지이다. 첫 번째는 빠르게 제품을 개발하여 이터레이션을 진행할 수 있다. 초기 스타트업에서 PMF(Product Market Fit)를 찾기 위해 풀스택 개발자를 채용하거나 풀스택으로 개발하는 이유이다. 두 번째는 문제를 해결하는 데 있어서 더 좋은 해결 방법을 도출할 수 있다는 데 있다. 트레이드 오프를 계산할 때 넓은 시야로 문제를 조망하고 다른 관점에서 해결책을 고안할 수 있는 것이다.
크게 두 역할로 나눈다고 했을 때, 첫 번째 역할은 더 이상 개발자의 역할이 아니게 될 것이다. 어느 정도의 품질로 제품을 개발하는 일은 디자이너나 기획자분들이 더 빠르고 더 잘하는 일이 되지 않을까? 사실 Framer site나 No-code 도구들이 빠르게 발전하고 있기 때문에 꼭 Agent가 아니더라도 언젠가 일어났을 일이라고 생각한다. 가지고 있던 한계를 Less code로 극복하되, 이마저 LLM이 생성한다면 쉽게 해결되지 않을까 싶다.
두 번째 역할로서의 제품 개발자의 역할은 여전히 유효할 것으로 생각한다. 제품 전체를 바라보고 개발하는 것은 여전히 중요하다. 나무를 잘 가꾸는 것도 중요하지만 전체적인 숲을 잘 관리하는 것도 중요한 일이기 때문이다. 다만 이제 더 중요한 것은 '잘 만드는 것'이라고 생각한다.
품질
같은 값이면 다홍치마
생산성 증대는 이미 이뤄지고 있고 모두가 제품을 빠르게 만들 수 있는 소프트웨어 양산형 시대가 됐다면 이젠 무엇을 해야 할까.
- 기능은 당연한 것이 되고 경험이 중요하게 여겨지지 않을까? 더 사용자 친화적인 인터페이스를 구현하고 유려한 인터페이스가 중요해지지 않을까?
- 제품이 고객으로 생각하는 사용자 풀이 더 작아지지 않을까? 더 작은 세그먼트의 사용자를 위한 제품을 만들고 그들만을 위한 기능이 추가되지 않을까?
이미 여러 포화된 시장에서 보인다. 대표적으로 의류 시장이 있다. 옷의 역할은 기능을 넘어섰다. 동일한 기능의 옷들이 차고 넘친다. 자동차 시장은 어떤가. 기존엔 자동차라는 하나의 분류였다면 크기에 따라 경차, 중형자, 소형 SUV, 중형 SUV 등 세분화됐다. 고객의 유형에 따라 세단, 스포츠카, 캠핑카가 등장했다.
소프트웨어도 비슷한 길을 가지 않을까. 고객들의 요구는 다양해질 것이고, 품질에 대한 기준은 높아질 것이다. 그리고 시장은 그에 맞춰서 움직일 것이다. 우리는 이미 대안이 있다면 좋은 것을 사용한다. 불편한 소프트웨어는 사용하지 않는다.
장인 정신
그래서 잘 만들기 위해 구체적으로 무엇을 해야 하는가? 잘 만들기 위해선 장인정신이 필요하다. 전문성이 필요하다. 데이터를 잘 다룬다던가, 경험을 잘 설계하고 잘 구현한다던가. 모든 영역에 대해서 전문가가 되긴 어렵다. 자연스럽게 전문성의 세분화가 이뤄진다. 지금보다 더 세분화가 될 수도 있을 것 같다.
플랫폼
생산성도 잃지 않으면서 잘 만들기 위해선 플랫폼이 중요해진다. 플랫폼이라 하면 거시적 관점에서의 시스템이 될 수도 있고 미시적 관점에서 작은 모듈이 될 수도 있다. LLM이 제품을 만들기 위한 기반을 잘 다듬어두는 플랫폼이 중요해질 것 같다. 개발자는 플랫폼을 활용하여 제품을 개발하는 일보다 오히려 시스템, 플랫폼 사이드의 최적화가 중요해진다면 이런 방향으로 전문성의 세분화로 이어질 수 있을 것 같다.
짧은 상상
지금까진 지금 일어나고 있는 일에 대한 생각이었다. 앞으로 조금 더 나간다면 Agent가 결과물까지 산출하고, 그 결과물을 리뷰하면 되지 않을까. 인간이라는 것 자체가 직업이 되어 인간 입장에서 제품을 사용하고 피드백을 주는 것이다. 마치 여론 조사에 응하는 것처럼.
고객은 실제로 자기가 무엇을 필요로 하는지 모른다. 문제를 정의하는 것이 중요한 이유다. 앞서 정의한 문제를 전달한다고 했는데, Agent는 인간이 마주하고 있는 문제, 앞으로 마주하게 될 문제들을 확률적으로 계산하고 이러한 문제들을 해결하기 위해 여러 시도를 할 수 있다. 속도도 빠를 것이라 여러 실험을 병렬적으로 진행할 수 있다. 스스로 문제를 정의하고 해결책을 도출하여 결과물을 만들어낸다면 우린 검수만 하면 되지 않을까.
사진을 보고 고양이인지 개인지를 가르쳐줬다면 이젠 만든 결과물이 인간에게 유용한지 유용하지 않은지를 알려주는 것이다. 센서를 달고 제품을 사용하며 현실 세계의 물리학을 학습시키는 것이다. 근데 이것도 잠깐일 것 같다.
마무리
원래 3월 초 글의 주제를 정리하기 시작했을 때는 제목이 'AI 파도에 서핑하는 개발자'였다. 그러다가 파도를 쓰나미로 바꾸고 어찌해야 할지 몰라 그냥 개발자로 바꿨는데, 글을 다 쓰고나서 이 불확실성을 표현할 비유가 떠오르지 않아 모든 수식어를 내려놓았다.
최근 개발하면서 느꼈던 느낌과 생각들을 상상을 얹어 정리했다. 앞으로 어떻게 발전해 나갈지, 이미 어떻게 발전되어 있을지 궁금하다.
정리
- 협업 대상으로서의 Agent를 받아들이고 이해하자.
- 어느 정도 수준의 프로토타이핑은 더 이상 개발자들의 역할이 아니게 된다.
- 새로운 역할이 생기겠지만 그만큼 기존의 역할도 더 깊어질 것이다.
- 이제 잘 만드는 것이 중요해진다.
- 오히려 시스템, 플랫폼 사이드로의 전문성이 중요해지지 않을까?
생각하지 않으면 사는 대로 생각하게 된다. 그리고 생각하지 않으면 AI가 이끄는 대로 생각하게 된다.
2월 릴리즈 노트, Worth the click에서 'Taste'에 대한 생각을 짧게 남겼다. 이 글에 영향을 준 글이라 링크를 남긴다. 지난 AI, 그리고 하고 싶은 것 글에선 우린 무엇을 해야 할까에 대한 생각을 정리했고 이번엔 개발에 대한 생각을 정리했는데, 다음번엔 학습에 대한 생각을 정리하려고 한다.